Network Utility User's Guide

Chapter 18. Sample Host Definitions

This appendix contains examples of host definitions for the Network Utility in the configurations used in this manual.

Specifically, definitions for the following environments are presented:

• LSA
• LCS
• MPC+

Additionally, the differences between a Network Utility with an ESCON channel adapter and a parallel channel adapter are highlighted.

For more information on defining the Network Utility to the host, refer to the IBM 2216 Nways Multiaccess Connector Software User's Guide, SC30-3886.

Overview

There are three steps to define a channel-attached Network Utility to the host:

1. Define the Network Utility to the host channel subsystem

   This will be done either from the I/O configuration program (IOCP) or the Hardware Configuration Definition (HCD), depending on your MVS version. (HCD requires MVS/ESA SP version 4.2 or later with APAR# OY67361.)

   The definition statements are slightly different for an ESCON channel-attached device than for a parallel channel-attached device. An example of these definitions is given in Sample Host IOCP Definitions.

2. Define the Network Utility as a control unit to the host operating system

   For most systems, the definitions are the same for an ESCON adapter as they are for a parallel channel adapter. Obviously, they depend on the operating system being used. An example of these definitions is given in Defining the Network Utility in the Operating System.

3. Define the Network Utility to the host TCP/IP or VTAM

   These definitions depend on whether you are defining an LSA (SNA), an LCS (TCP/IP), or an MPC+ (SNA and/or TCP/IP) interface on the Network Utility. Section VTAM Definitions shows examples of the required VTAM definitions. Section Host IP Definitions shows examples of the required TCP/IP definitions.

Definitions at the Channel Subsystem Level

You make definitions at this level via the IOCP or with HCD. If HCD is available, you will probably want to use it. HCD offers an improved method of defining system hardware configuration. With HCD several complex steps required for entering hardware configuration data can be accomplished using an interactive dialog. This chapter presents only the IOCP macros that would be generated from HCD.

Sample Host IOCP Definitions

An example of the definitions required in the host I/O Configuration Program (IOCP) for a Network Utility configured with an ESCON adapter is shown in Figure 18-1.

Figure 18-1. Sample Host IOCP Definitions for the Network Utility (ESCON)

CHPID                   PATH=((05)),TYPE=CNC
CNTLUNIT                CUNUMBR=1E0,PATH=05,CUADD=0,
                        UNITADD=((E0,32)),LINK=3C,UNIT=3172
IODEVICE                UNIT=3172,ADDRESS=((1E0,32)),
                        CUNUMBR=1E0
 

The following sections describe the IOCP macros that you need for defining the Network Utility at the host.

RESOURCE Statement

This identifies the host logical partitions (LPARs) by name and number. This statement is not present if the host is not partitioned as is the case in the example above.

• PART=((name1,x),(name2,y)...(nameX,z))

  The name identifies the LPAR and is used in the rest of the channel path definition. The number is the corresponding LPAR number. The LPAR number is used in defining the subchannel on the Network Utility. If the host is not partitioned, the LPAR number is always 0.

Channel Path ID (CHPID) Statement

The CHPID identifies the type of channel connection and who uses it.

• PATH=x

  This uniquely identifies the channel path. This value is often called the "CHPID number".

• TYPE=CNC

  This indicates that the channel is an ESCON channel. The channel type is CNC for ESCON and BL for block multiplexor (Parallel Channel Adapter).

• SWITCH=x

  This identifies which ESCON Director is in this path. If no director is being used, this parameter is omitted.

• SHARED

  This indicates that the CHPID can be used by multiple LPARs simultaneously. If not present, only one LPAR can use the CHPID at a time.

• PARTITION=(name1,name2,...,nameX)

  This is one form of the PARTITION parameter and it contains an access list of LPARS that indicates which partitions have access to this channel. The names must be included in the RESOURCE statement.

• PARTITION=((name1,...,nameX),(name2,...,nameY))

  This is the other form of the PARTITION parameter. In this form, the first grouping of names is the access list of LPARs, as above. The second grouping is the list of candidate LPARs that an operator could configure to have access to the channel. The second grouping will have at least the same LPARs as the first grouping and it may specify additional LPARs also.

Control Unit (CNTLUNIT) Statement

This statement, along with the IODEVICE statement, defines the path from the host to the Network Utility. The CNTLUNIT and IODEVICE statements occur in pairs. If multiple LPARs are being defined to use a single CHPID, there must be a CNTLUNIT and IODEVICE statement for each LPAR.

• CUNUMBR=x

  This is an identifier for the control unit definition.

• PATH=x

  This number identifies the CHPID being used.

• UNIT=3172

  This identifies the type of control unit at the other end of the channel. The value is always 3172 when talking to a Network Utility. The IBM 3172 was the predecessor of the Network Utility ESCON channel function.

• CUADD=x

  This value identifies the control unit address of the Network Utility. The default is 0.

• UNITADD=((addr,number))

  This defines the range of addresses reserved for this control unit, where:

  addr

  is the hex address of the first subchannel assigned to this control unit

  number

  is the decimal number of subchannels being assigned to this control unit

  The example above defines a range of 32 control unit addresses, or subchannels, starting from E0 hex and going upwards. The device addresses specified on the Network Utility LCS, LSA, or MPC+ interface definition must be from within this range. The Network Utility can use a maximum of 64 subchannels.

• LINK=xx

  The value for the LINK parameter should be set to the port of the ESCON Director (ESCD) that the Network Utility is attached to. Because the ESCD is a switch, you can think of the link parameter as the phone number that the host will use to reach the Network Utility through the switch.

IODEVICE Statement

This statement, along with the CNTLUNIT statement, identifies the Network Utility connection to the host.

• ADDRESS=(addr,number)

  This parameter identifies the range of addresses to the rest of the host, where:

  addr

  is the hex address being assigned to the first address reserved

  number

  is the decimal number of subchannels reserved

  This address is different from the UNITADD. It is used in the TCP/IP profile (for LCS), the VTAM XCA Major Node Definition (for LSA), and the VTAM TRL (for MPC+) to identify the subchannels being used.

• CUNUMBR=x

  This identifies the corresponding CNTLUNIT statement to this IODEVICE statement. While the value for this parameter has to be the same for both the CNTLUNIT and the IODEVICE macros, it does not have to relate to any other parameter. It is a good idea, however, to make it the same value specified in the ADDRESS parameter in the IODEVICE macro. The value for CUNUMBR has no significance outside the Channel Path Definition.

• UNIT=3172

  This identifies the type of device that is downstream. It should always be 3172 if the control unit is a Network Utility. The IOCP software in the host does not look at this field. If you are migrating from an IBM 3172 to the Network Utility, you might have a value of UNIT=SCTC in the existing IOCP statement. This should be changed to 3172 for the Network Utility.

• PARTITION=(name)

  This is the device candidate list and it contains a list of one or more LPARs that have access to the device. This list is a subset of the list of LPARs specified in the CHPID statement and it is used to restrict which LPARs in the channel candidate list are allowed to use these devices. If the host is not partitioned, this field will not be present.

Figure 18-2 shows an example of the IOCP statements for defining a Network Utility with a Parallel Channel Adapter (PCA).

Figure 18-2. Sample Host IOCP Definitions for the Network Utility (PCA)

CHPID                   PATH=((05)),TYPE=BL
CNTLUNIT                CUNUMBR=640,PATH=05
                        PROTOCL=S4,UNIT=3172
                        SHARED=N,UNITADD=((40,32))
IODEVICE                UNIT=3172,ADDRESS=((640,32))
                        STADET=N,CUNUMBR=640,TIMEOUT=Y
 

Note the following points concerning the IOCP statements for a Network Utility with a PCA.

• The TYPE is BL for Block Multiplexer

• PROTOCL parameter can be set to the following values, depending on the device capability:

  D

  Direct-Coupled Interlock (DCI) mode

  S

  Maximum 3.0 Mbps data streaming speed

  S4

  Maximum 4.5 Mbps data streaming speed

  For the Network Utility, set the value to S4. The transfer mode and channel parameter must conform with the PCA setting for transfer mode and channel transfer speed.

• The UNIT parameter on the CNTLUNIT and IODEVICE statements must be set to 3172.

• When an ESCON Converter is the channel path, the CHPID TYPE parameter must be set to CVC, otherwise it is set to BL.

Defining the Network Utility in the Operating System

The following sections describe the definitions needed for various host operating systems.

Network Utility Definition for VM/SP

You must define the Network Utility to a VM/SP operating system by updating the real I/O configuration file (DMKRIO) with entries for the Network Utility in the RDEVICE and the RCTLUNIT macros. In the following example, 640 is the base unit address and the size of the address range is 32.

RDEVICE ADDRESS=(640,32),DEVTYPE=3088
RCTLUNIT ADDRESS=640,CUTYPE=3088,FEATURE=32-DEVICE

Network Utility Definition for VM/XA and VM/ESA

You must define the Network Utility to a VM/Extended Architecture (VM/XA or VM/ESA operating system by updating the real I/O configuration file (HCPRIO) with an entry for the Network Utility in the RDEVICE macro. In the following examples, 640 and 2A0 are base control unit addresses. The address range size, as defined in the UCW or IOCP, is 8 in both examples.

The following example is a VM/XA HCPRIO definition:

RDEVICE ADDRESS=(640,8),DEVTYPE=CTCA

The following example is a VM/ESA HCPRIO definition:

RDEVICE ADDRESS=(2A0,8),DEVTYPE=CTCA

Network Utility Definition for MVS/XA and MVS/ESA without HCD

You must define the Network Utility to an IBM Multiple Virtual Storage/Extended Architecture (MVS/XA) or MVS/ESA operating system by updating the MVS Control Program with an entry for the Network Utility in the IODEVICE macro.

For ESCON channels, an example IODEVICE macro is:

IODEVICE UNIT=3172,ADDRESS(540,8)

For parallel channels, an example IODEVICE macro is:

IODEVICE UNIT=CTC,ADDRESS(640,8)

The base control unit addresses are 540 and 640. The address range size, as defined in the UCW or IOCP, is 8 in both examples.

Network Utility Definition for MVS/ESA with HCD

The hardware configuration definition (HCD) component of MVS/ESA SP Version 4.2 and 4.3 with APAR #OY67361 offers an improved method of defining the system hardware configuration for Network Utility. You can accomplish the several complex steps required for entering hardware configuration data by using an interactive dialog with HCD.

The required configuration data for the Network Utility is:

• When using HCD with APAR # OY67361, define the Network Utility as (UNIT=3172). For example,

  IODEVICE UNIT=3172,ADDRESS(740,8)
  

• Without HCD, define the Network Utility for:

  • Parallel channels as a 3088 device (UNIT = 3088 or CTC)

    IODEVICE        UNIT=CTC,ADDRESS(840,8)
    

  • ESCON channels as a serial CTC device (UNIT = SCTC)

    IODEVICE        UNIT=SCTC,ADDRESS(A40,8)
    

Notes:

1. If you are using HCD for MVS Version 4 to define your ESCON host connection, you will need APAR # OY67361 to obtain the UIM support for the device definition (UNIT=3172).

2. When you are migrating your IOCP definition and operating system definitions to the HCD environment, it is important that you change all Network Utility device statements to device type (UNIT=3172).

Network Utility Definition for VSE/ESA

You must define the Network Utility to a VSE/ESA operating system by supplying an ADD statement for each channel unit address at initial program load (IPL) time. Code the device type on the ADD statement as CTCA, EML as shown in the following example:

ADD 640,CTCA,EML

The base control unit address is 640 in the example. For the number of channel unit addresses added, increment the IOTAB storage macro by this count.

VTAM Definitions

This section gives sample VTAM definitions for an XCA major node, an MPC+ local PU and Transport Resource List (TRL) major node, and an example of defining VTAM for APPN and DLUR support. It also shows an example of a switched major node for a PU in a TN3270 server. This section is not meant to be a complete reference on the subject. For more information on configuring VTAM, refer to the CS OS/390 Resource Definition Reference, SC31-8565.

VTAM XCA Major Node Definition

When defining a channel gateway using LSA to VTAM, a definition for an External Communications Adapter (XCA) is required. This definition is the same as that used for an IBM 3172. An example is shown in Figure 18-3.

Figure 18-3. XCA Major Node Definition Sample for LSA Direct Connection

**********************************************************************
RAINETU VBUILD TYPE=XCA     (1)
 
**
**
RANETUP  PORT  ADAPNO=0,    (2)                        * X
               CUADDR=285,    (3)                      * X
               MEDIUM=RING,     (4)                    * X
               SAPADDR=4,         (5)                  * X
               TIMER=60
**
**********************************************************************
RANETUG1 GROUP DIAL=YES,CALL=INOUT,DYNPU=YES
*
RANETUL1 LINE ANSWER=ON,ISTATUS=ACTIVE
RANETUP1 PU   ISTATUS=ACTIVE
RANETUL2 LINE ANSWER=ON,ISTATUS=ACTIVE
RANETUP2 PU   ISTATUS=ACTIVE
RANETUL3 LINE ANSWER=ON,ISTATUS=ACTIVE
RANETUP3 PU   ISTATUS=ACTIVE
RANETUL4 LINE ANSWER=ON,ISTATUS=ACTIVE
RANETUP4 PU   ISTATUS=ACTIVE
RANETUL5 LINE ANSWER=ON,ISTATUS=ACTIVE
RANETUP5 PU   ISTATUS=ACTIVE
RANETUL6 LINE ANSWER=ON,ISTATUS=ACTIVE
RANETUP6 PU   ISTATUS=ACTIVE
RANETUL7 LINE ANSWER=ON,ISTATUS=ACTIVE
RANETUP7 PU   ISTATUS=ACTIVE
RANETUL8 LINE ANSWER=ON,ISTATUS=ACTIVE
RANETUP8 PU   ISTATUS=ACTIVE
RANETUL9 LINE ANSWER=ON,ISTATUS=ACTIVE
RANETUP9 PU   ISTATUS=ACTIVE
 

LINE Statement

The CALL field can be one of the following:

• IN means only remote devices may establish connections.
• OUT means only VTAM can initiate connections.
• INOUT connections may be initiated at either end.

If VTAM is going to dial out, the Switched Major Node definition must specify a destination with a PATH statement.

An asterisk in the first column indicates a statement has been commented out, and should be ignored. A character in the last column indicates the next line is a continuation of this line.

VTAM Definitions for an MPC+ Connection

An MPC+ connection requires entries in two VTAM control blocks:

• The Local Major Node
• The Transport Resource List (TRL) Major Node

Figure 18-4 shows a sample definition for a local SNA major node for a Network Utility MPC+ connection. This is the local PU that resides in VTAM that supports the channel connection defined in the TRL. The connection type must be APPN and you also need to enable HPR.

Figure 18-4. VTAM Local Major Node Definition

LOCNETU  VBUILD TYPE=LOCAL
MPCNETUP PU    TRLE=MPCNETU,
               XID=YES,
               CONNTYPE=APPN,
               CPCP=YES,
               HPR=YES
 

Notes:

1. TYPE must equal LOCAL on the VBUILD statement.

2. TRLE identifies the TRL being used. The name must match the name of an existing TRL.

3. XID indicates whether XIDs will be exchanged. It must be XID=YES.

4. CONNTYPE must be set to CONNTYPE=APPN since APPN is the only protocol that VTAM uses with an MPC+ connection.

5. CPCP specifies that CP-CP connections with APPN can be established over this MPC+ connection. This could be either set to YES or NO, depending upon your APPN topology.

6. HPR specifies that APPN HPR traffic can flow over this MPC+ connection. HPR is normally used by default, but setting this value to YES ensures it. This is important because an MPC+ connection requires RTP (and HPR).

Next, you need a transport resource list for the MPC+ connection from the Network Utility. An example definition is shown in Figure 18-5.

Figure 18-5. VTAM Transport Resource List (TRL) Definition

        VBUILD TYPE=TRL
MPCNETU TRLE   LNCTL=MPC,
               MAXBFRU=9,
               READ=280,
               WRITE=281,
               MPCLEVEL=HPDT,
               REPLYTO=3.0
 

Notes:

1. TYPE must be TRL.

2. MPCNETU is the name that identifies the TRL. It must match what is specified in the TRLE= field in the local major node definition. (See Figure 18-4.)

3. LNCTL identifies the connection type. It must be LCNTL=MPC.

4. MAXBFRU is the number of 4K pages per read subchannel.

5. READ/WRITE specifies the subchannels in the MPC+ group, and indicates their direction. The subchannel numbers must be in the range of addresses specified in the IODEVICE statement in the IOCP definition. There can be multiple READ and WRITE parameters in the TRLE statement but there must be at least one of each.

   Note:

   The designations READ and WRITE here are from the HOST perspective. In the Network Utility MPC+ definition, the designations are from the Network Utility perspective. Therefore, subchannels designated as READ on the host must be designated as WRITE on the Network Utility, and vice versa.

6. REPLYTO is the reply timeout value in seconds.

VTAM Definitions for APPN

If VTAM is configured for DLUS, then it must be an APPN network node. Configuring VTAM as an APPN network node requires certain parameters to be specified in the VTAM start-up parameters. These are shown in Figure 18-6. Set the CONNTYPE to APPN and the NODETYPE to a Network Node (NN).

Figure 18-6. VTAM Start-up Parameters

ASYDE=TERM,IOPURGE=5M,
CONFIG=I0,
CONNTYPE=APPN,
CPCP=YES,
CSALIMIT=0,
DYNADJCP=YES,
ENCRYPTN=NO,
GWSSCP=YES,
HOSTPU=ISTPUS18,
HOSTSA=18,
HPR=RTP,
NETID=USIBMRA,
NODETYPE=NN,
NOTRACE,TYPE=VTAM,IOINT=0
PPOLOG=YES
SORDER=APPN,
SSCPDYN=YES,
SSCPID=18,
SSCPNAME=RAI,
SSCPORD=PRIORITY,
SUPP=NOSUP,
TNSTAT,CNSL,
VRTG=YES
OSITOPO=LLINES,
OSIMGMT=YES
XNETALS=YES
 

VTAM Static Definition of TN3270 Resources

VTAM definitions are required for the PUs used by the TN3270E Server. You need a switched major node definition for each PU in the TN3270E server. For example, each PU in the TN3270E server can support up to 253 LUs. If you need 500 3270 sessions, then you will need 2 PUs in the router and 2 PU definitions in VTAM.

Figure 18-7 shows an example of a VTAM switched major node definition for a TN3270E server PU that is connected via DLUR and APPN.

Figure 18-7. VTAM Definitions for a TN3270E Server PU (DLUR/APPN)

LOCNETU  VBUILD TYPE=SWNET
MNETUA  PU     ADDR=01,ISTATUS=ACTIVE,VPACING=0,                       *
               DISCNT=NO,PUTYPE=2,SSCPFM=USSSCS,USSTAB=US327X,         *
               IDBLK=077,IDNUM=02216,IRETRY=YES,MAXDATA=521,           *
               MAXOUT=7,MAXPATH=8,PASSLIM=7,PACING=0,ANS=CONTINUE
********************************************************************
PNETUA   PATH  PID=1,DLCADDR=(1,C,INTPU),DLCADDR=(2,X,07702216),       *
               DLURNAME=MNETUA
********************************************************************
JC7LU2   LU    LOCADDR=2
JC7LU3   LU    LOCADDR=3
JC7LU4   LU    LOCADDR=4
 

Figure 18-8 shows an example of a VTAM switched major node definition for a TN3270E server PU that uses a subarea connection to the host.

Figure 18-8. VTAM Definitions for a TN3270E Server PU (Subarea)

 LSAP08T VBUILD TYPE=SWNET
 PUPS08T PU ADDR=01,IDBLK=077,IDNUM=12244,MAXOUT=7,PACING=0,VPACING=0,
                DLOGMOD=B22NNE,PUTYPE=ANY,
                SSCPFM=USSSCS,MAXDATA=2000,MODETAB=LMT3270
 PT08LU2 LU LOCADDR=02,LOGAPPL=TSO
 PT08LU3 LU LOCADDR=03,LOGAPPL=TSO
 PT08LU4 LU LOCADDR=04,LOGAPPL=TSO
 PT08LU5 LU LOCADDR=05,LOGAPPL=TSO
 PT08LU6 LU LOCADDR=06,LOGAPPL=TSO
 

The following sections provide an overview of the statements in the Switched Major Node Definition.

VBUILD Statement

The TYPE field must be TYPE=SWNET.

PU Statement

This statement defines the type of data flow and the destination. The pertinent parameters are:

• ADDR is an identifier.

• MAXDATA is the maximum packet size VTAM will support over this interface. This value will be negotiated down with the Network Utility during the XID exchange.

• IDBLK/IDNUM identify the remote device when VTAM is communicating with PU 2.0 (dependent) devices.

LU Statement

These statements define the logical units (LUs) that can be contacted through this PU. The name on the left of each statement is the name that the host uses to address each LU. The LOCADDR is used by the Network Utility to identify the correct LU in VTAM.

PATH Statement

If VTAM is going to dial out, the Switched Major Node definition must specify a destination with a PATH statement. The path statement will be different depending on whether the TN3270E server attaches via a Subarea or a DLUR/APPN connection.

For a subarea connection, the format is:

PATH DIALNO=xxyyzzzzzzzzzzzz

where:

• xx is a place holder
• yy is the destination SAP number
• zz is the destination MAC address

The example in Figure 18-8 does not have a PATH statement because in this example, the downstream PU will contact VTAM instead of VTAM dialing out to the device.

The example in Figure 18-7 shows a PATH statement for a TN3270E server PU that is using DLUR to connect to the host. Here, the PATH statement identifies the CP name of the Network Utility (MNETUA) via the DLURNAME parameter. This is needed in order for the LU6.2 conversation between the DLUR and DLUS to be established. Once this session has been established, the SSCP-PU session between VTAM and the TN3270E server PU will be established using the IDBLK/IDNUM value specified by DLCADDR=(2,X,07702216).

VTAM Dynamic Definition of TN3270 Resources

For the latest information, please refer to "Dynamic Definition of Dependent LUs".

Host IP Definitions

Defining the Network Utility to the host for a TCP/IP connection requires you to make changes to the host TCP/IP profile. This section gives an overview of the relevant statements that need to be changed.

DEVICE Statement

This statement defines the subchannel pair being used by TCP/IP. The format is:

DEVICE  name  LCS  subchannel

where:

• name identifies the subchannel path being used. It has local significance only, and can be anything.

• subchannel identifies the even subchannel being used for this connection. This value comes from the IODEVICE statement in the IOCP definition. When specified, that subchannel and the next one are both being used.

A TCP/IP profile must contain one DEVICE statement for each subchannel pair being used.

LINK Statement

This statement identifies which LCS interfaces on the Network Utility are being used on a given subchannel pair. The format is:

LINK name lantype lannumber devicename

where:

• name identifies the LCS interface. It has local significance only, and can be anything.

• lantype identifies the type of LAN interface that the Network Utility LCS interface is emulating. The allowable values are:
  • IBMTR for Token-Ring
  • ETHERNET for Ethernet V2
  • 802.3 for Ethernet (IEEE 802.3)
  • ETHERor802.3 for either Ethernet format accepted
  • FDDI for FDDI

• lannumber identifies which LCS interface on the Network Utility is being used. The lannumber is generated sequentially for each lantype on the Network Utility when you add an LCS interface. The lannumber can be found by entering list nets from the ESCON console in Talk 5. Note that the lannumber is not the net number. Having the wrong lannumber is the single most common configuration error for an LCS interface.

• devicename correlates the LCS interface to a subchannel pair. It must match a previously defined DEVICE statement.

There can be multiple LINK statements associated with a single DEVICE statement. There must be an LCS interface on the Network Utility for each LINK statement.

HOME Statement

This statement specifies the IP address(es) of the host TCP/IP stack. The format is:

HOME     ipaddress1     link1
         ipaddress2     link2

where:

• IpaddressX specifies an IP address on the host.

• LinkX specifies which link is associated with this IP address.

There must be only one HOME address for each LINK statement. The HOME address must be in the same IP subnet as the IP address of the LCS interface in the Network Utility, but they must be different addresses.

GATEWAY Statement

This statement identifies the IP routing information for the host. It is divided into three sections:

• Direct Routes are routes directly connected to the host. The subnet containing the Network Utility LCS interface is a direct route.

• Indirect Routes are routes that are accessible via routers. The subnets of the LANs on the Network Utility are indirect routes, for example.

• Default Route is the route to be used if the host doesn't have a direct or indirect route to an IP address.

Direct Routes

The format for Direct Routes is:

network firsthop linkname pktsize submask subvalue

where:

• network is the non-subnetted part of the IP address.

• firsthop indicates the IP address of the next hop in the IP network. For Direct Routes, this should be an equal sign (=).

• linkname identifies which link the host should use to get to the addresses on this route. For routes accessible via the Network Utility, this should be the name from the LINK statement associated with the LCS interface on this subnet.

• pktsize is the maximum frame size to be used on the interface. It should be less than or equal to the packet size defined in the LCS configuration on the Network Utility. A value of DEFAULTSIZE indicates the default packet size will be used.

• submask specifies the subnet mask used on this link. The subnet mask should correspond to the subnet mask defined for the LCS interface in the IP configuration on the Network Utility. This field may also be set to HOST to identify a point-to-point connection. In this case, the network field should contain the full IP address of the LCS interface.

• subvalue specifies the subnetted part of the IP address, and together with the network field, should fully specify the IP subnet associated with this LCS interface.

Indirect Routes

The format for Indirect Routes is:

network firsthop linkname pktsize submask subvalue

where:

• network is the full address of the IP subnet.

• firsthop indicates the IP address of the next hop in the IP network. For Indirect Routes accessible via the Network Utility, this should be the IP address of the Network Utility LCS interface.

• linkname identifies which link the host should use to get to the addresses on this route. For routes accessible via the Network Utility, this should be the name from the LINK statement associated with the LCS interface on this subnet.

• pktsize is the same value as for Direct Routes.

• submask should either be 0 or blank if the network field contains the full subnet address.

• subvalue should be left blank if there is no subnet mask specified.

Default Routes

The format for Default Routes is:

network firsthop linkname pktsize submask subvalue

where:

• network should be DEFAULTNET.

• firsthop indicates the IP address of the next hop in the IP network. For Default Routes to the Network Utility, this should be the IP address of the Network Utility LCS interface.

• linkname identifies which link the host should use to get to the addresses on this route. For routes accessible via the Network Utility, this should be the name from the LINK statement associated with the LCS interface on this subnet.

• pktsize is the same value as for Direct Routes.

• submask should either be 0 or blank.

• subvalue should be blank.

START Statement

This statement causes the specified subchannels to be started. The format is:

START devicename

where devicename is the name on the DEVICE statement above.

There must be a START statement for every DEVICE statement if the customer wishes to activate the devices when TCP/IP is started. If the START statement is not here, the devices can be started using the OBEY file. Note that the name here is the one from the DEVICE statement, not the LINK statement. Note also that the Network Utility LCS interface will remain in the DOWN state until the START has been issued from TCP/IP.

Host TCP/IP Definitions for LCS

This section gives you examples of the above statements required if you are defining an LCS connection.

1. DEVICE statement:

   DEVICE LCS1 LCS 210
   

   where LCS1 is the device name being defined, LCS is the type of device, and 210 is the host read (Network Utility write) subchannel used for this definition.

2. LINK statement

   LINK ETHLCS1 802.3 0 LCS1
   

   where ETHLCS1 is the link name, 802.3 is the LAN type to which the LCS interface attaches on the Network Utility, 0 is the LAN number assigned by the Network Utility, and LCS1 is the name of the device (from the device statement above).

   Note:

   Remember that the LAN number is automatically assigned by the Network Utility when you define the LCS interface. You can obtain it by issuing a list all command from the ESCON Config> prompt in the talk 6 process on the Network Utility console.

3. HOME command

   HOME 9.24.106.72 ETHLCS1
   

   where 9.24.106.72 is the IP address of this LCS interface and ETHLCS1 is the name of the link.

4. GATEWAY command

   GATEWAY 9.24.106   9.24.106.1   ETHLCS1   4096  0
   

   where 9.24.106 is the IP address for the network, 9.24.106.1 is the IP address of the default router, ETHLCS1 is the link name defined by the LINK statement above, 4096 is the MTU size, 0 is the subnet mask, and the subnet value has been left blank.

5. Activate the TCP/IP profile

   To activate the device defined in step 1, issue the following command:

   start lcs1
   

Host TCP/IP Definitions for MPC+

The steps for configuring TCP/IP in the host for an MPC+ connection are the same as for an LCS connection. However, the command syntax for the device and link commands is slightly different. For an MPC+ connection, the syntax for the device command is:

DEVICE IPTRL1 MPCPTP

where IPTRL1 is the name of the TRL that this connection will use and MPCPTP specifies an MPC point-to-point link.

To define the link, the syntax is:

LINK LINK1 MPCPTP IPTRL1

where LINK1 is the link name and the other two parameters are the same as those used in the device statement.